上一篇文章中介紹的報價方法，在我這一年多來的實驗結果，碰過很多無法接受或是仍舊希望要有報價單、合約書的客戶，面對這類的狀況，我會持續溝通這樣合作的好處，進而先嘗試合作一些小案子看看，讓他們實際感受到這樣的模式對雙方都有益處，另一方面可以讓自己站在客戶角度來思考他們的問題，提供真正對他們有幫助的建議，這樣才能建立信任並保持長久的合作關係。
當然，任何方法用在真實世界總是會遇到很多挑戰，下面整理出一些我常被問到的問題：
就算有訂金、報價單、合約書也常常有做到一半人不見或是因為各種理由收不回尾款的案子，所謂的保障，對雙方來說就是時間到了看得到成果並且拿得到酬勞，一堆文件作業也都是為了要確保雙方能信守承諾、當其中一方背信時有求償損失的備案而已。
對接案者來說，時薪計價最大的風險就是在於一個月的款項請不到，也就是白做工一個月，相較於以往好幾個月才能請一次款，只損失一個月的工作小時數已經是不幸中的大幸，而且只花一個月甚至幾週的時間就可以認識一間公司或一個人，不用花上好幾個月或好幾年的時間才知道，已經算是少走很多冤枉路了。
當然，如果要上法院，每週定期回報記錄 Email 都能拿來作為證據，但還是要衡量官司打下去的成本是否會讓自己深陷泥沼，畢竟一般有規模的公司都會有法務部門來專責處理法律糾紛，程式接案者或是小型工作室這方面就會比較吃虧。
對發案方來說，合作一個月的過程中就能知道對方的工作方式，像是有沒有定期回報進度、是否有固定產出，如果發現苗頭不對，不用等到一個月，可能只要幾週的時間就能知道是否要提早結清工作時數並尋找下一間合作廠商，如果有合約在，片面解約都是需要付出成本的，所以為了避免罰則，縱使知道合作對象有問題，還是必須要硬撐下去走完合約，通常最後的結果都不會太好。
在客戶需求還沒有完成需求確認、操作流程等等的功能細節前，所有的估時都是憑著過去經驗來做預測的，就像要做一個購物網站，基本會有的功能像是購物車、結帳、金流、物流串接等等，這些都有過去的時數可以參考，但每家公司的商業情境不同，管理需求也不同，因此實際執行上一定會跟當初預估的工作項目有所落差。
但透過每週的定期回顧，就會慢慢釐清整個專案到底有多大，以及目前的完成進度百分比，所以重點應該是放在持續的追蹤與溝通，只要能透明化專案的資訊，客戶就不會覺得計時是黑箱作業而產生不信任感。
一個專案最花時間的地方不是坐在電腦前面寫程式，而是釐清客戶的需求以及確認成品是否有達到客戶的商業目標，初期的需求溝通的越明確，就越能減少後期修改的時間，但要能協助沒有網站專業知識的客戶釐清需求是一門學問，而且很多時候懂得這些專業知識的客戶也會把功能變得錯綜複雜。
這是人之常情，在一個專案被發起時，公司內部會有許多的聲音需要整合，好的整合是可以排出優先順序，但大部分情況是所有需求都要實現，因此會產生矛盾與衝突，譬如說客服部希望在每頁的頁首可以放上明顯的客服信箱連結，以減少客服電話的量，但業務部希望放上聯絡電話，就能跟客戶進行直接銷售。
沒有整合好的需求就會變成 Email 跟聯絡電話同時以巨大的字級顯示在頁首，什麼都要顯眼最後就會變成什麼都不顯眼，這時候釐清客戶的需求後就能提供相對應的作法，譬如說在電腦版顯示 Email、手機版顯示電話號碼，或是採取 A/B test 來實驗怎麼放會比較好，這些都是接案者的經驗，這些經驗沒有辦法 Google 得到，因為這是根據客戶的情境所設計的。
問出正確的問題、提出有效的作法、幫助客戶釐清真正重要的目標，這就是開會時接案者所提供的價值，就像美劇上常看到的心理醫生諮詢一樣，開會計時才能把溝通成本具體化，進而改善溝通效率。
有些客戶會質疑某些工作項目應該不會太複雜，花這麼多時間不太合理，這樣的情況有兩種，一種是任務沒有被正確的拆解，像是要做購物網站，購物功能只被當作是一個工作項目，購物功能包含有前台頁面的建置、商品管理、訂單管理、金物流串接、會員功能等等的細項，如果只列了一個購物功能可能就要會花費數十個小時來開發，從總小時數來看就會覺得這個單一工作項目花了太多時間。
另一種情況是客戶懂技術，他們以自己過去的經驗來判斷，所以會覺得某些時間的花費不合理。當然，工程師程度有高有低，做事的方式也會有所不同，這時候版本控管就是很好的溝通管道，因為程式碼的透明，客戶可以看到專案的原始碼，進而提出改善建議，也能判斷承接的工程師是否有辦法勝任這個工作。
所以當客戶質疑某工作項目的時數過多，根據拆解後的任務來進行討論就是很具體的作法，讓客戶可以明白每個待辦事項的目的，讓客戶知道這功能不是按下 Enter 就能搞定的，也或者是經過討論後我們會發現某些環節是不需實作的，藉此能降低整體開發時數。
不用計算。
通常保固指的是當專案已經過了約定結案日期後，如果還有發生程式上的臭蟲需要被修復的維護期間，在保固期間內的 Bug 修改，接案方有責任協助處理，這時候問題就來了，到底什麼是「臭蟲」？網站開不了？功能無法正常使用？實際用起來應該這樣改比較好？
關於臭蟲的定義也是一個吵不完的話題，常常客戶覺得是 Bug 的地方也許是某個邏輯沒有實作，但對於接案方來說這個邏輯並沒有在當初開發時接收到客戶的需求，而且結案時不都已經驗收過了，怎麼會現在才發現有這樣的問題？或是更多時候是使用者發現的 Bug，這些都讓臭蟲的定義很難有一個客觀的標準，除非在合約書裡面列出所有關於臭蟲的定義。
回到保固的定義，指的是過了「約定結案日期」後的維護，以敏捷式接案的定義來看，並沒有所謂的結案日期，因此也就沒有保固這樣的概念。網站上線後有問題，持續的以時薪計價進行修改臭蟲或是根據使用者回饋進行調整，就不用為了保固範圍而犧牲能讓網站變得更好的改進措施，而接案方也能提供更多實務上的建議讓網站達成商業目標。
很常聽到不建議接案者採用時薪報價的理由是因為動作越快能賺到的時數薪水越少，所以會很吃虧，但我的經驗是能把事情用最快的方法解決，藉此取得客戶的信任，才會有接不完的工作機會。
要知道，一個持續在經營的網站每天都會有各種大大小小的狀況需要排除，或是根據顧客的使用回饋進行調整，如果客戶信任你，你完全不用擔心會沒時數可以賺，反而會覺得好想趕快把功能完成讓客戶可以去拼業績，然後客戶業績因為你的協助有所提升，進而會再開更多需求來請你處理，達成一種正向循環。
只要你有能力可以解決客戶頭痛已久的問題，那麼公司就不會在意要用什麼方式跟你合作，然而可能還是需要一些文件來完成形式，尤其是請款流程，但因為你的價值，客戶會自己想辦法去設計出一套適合這樣合作模式的流程，你就不用再花時間去處理這些行政事務，進而專注在解決客戶的問題。
絕對賺得到。
以往專案的計價方式會分三期付款，頭款訂金，做到某個程度收二期款，客戶驗收完成後收尾款，更大一點的案子可能會分更多期，但除了頭款以外，剩下的款項都是要看客戶臉色，有個萬一的話，可能會長達好幾個月沒有收入，只能靠著頭款來過活，更不用說接一些二包或 N 包的政府標案，這是要等大包結案才有得拿的。
很多案子看似金額很高，但扣除掉實際執行的天數後，換算下來的月薪常常比上班族還要可憐，因此用時薪計價的月結方式，才能保持穩定現金流，每個月的工作有拿到酬勞事情做起來才會愉快。
當然，以上的說法不可能百分之百讓每一位客戶都能買單，公司有各種的行政流程與企業文化，有些還是堅持要有報價單合約書，並且採用專案方式計價，遇到這種也沒關係，就果斷的放棄這個機會吧，世界上一定還有其他的客戶值得你跟他合作，要記住，我們自己接案就是要獲得心目中理想的工作方式！
搞定報價後，下一篇我會介紹敏捷式接案該如何啟動專案，以及如何確認需求並且拆解成明確的執行項目。
本文同步發表於：https://oberonlai.blog/tw/wordpress-freelance-quotation-3/
iThome鐵人賽
看影片追技術